\documentclass[12pt,A4Paper]{report}
\usepackage{graphicx}
\usepackage{amsmath}
 
\parindent 0pt
\parskip 6pt

\begin{document}

\chapter{Conclusions}

This project has been successful. I have developed a system under Android which
wirelessly transfers data between two mobile devices using sound as the carrier
signal. This comprises 2 main project components, the encoder and the decoder.
In the encoding stage the sounds are frequency modulated to represent different
bytes, incorporating some error control and aiming to maximise the potential
reliability. In the decoding stage a Fast Fourier Transform is performed on the
received sound to retrieve the frequencies and decode them back into bytes. This
is where the error correction prepared for in the encoding stage takes place, by
altering the perceived frequencies to match the expected frequencies which can
be mathematically mapped to bytes. Both stages involve accessing the hardware on the mobile
device, namely the speakers and the microphone. Dolphin is written in such a way
that it can be inserted into other applications as a module and be used without
extensive knowledge of the inner workings.

\section{Initial success criteria}

All of the initial success criteria as described in my propsal have been met. An
additional data link layer has been implemented for Android. As demonstrated in
over 250 data transfers in Chapter 4, I have successfully converted a stream of
bits into a logical sound representation, and ensured that no two bit streams
have identical sound patterns unless the streams are themselves identical. I
have successfully decoded the sound back into a stream of bits on a seperate
device. I have carried out an evaluation of the transfer rates and reliability,
and created a superior implementation based on the results. In addition to this,
I have implemented an extension to the original project and full duplex
communication between devices is now available. I have shown in
Section~\ref{sec:performance} that using the proper variables, Dolphin is
capable of being accurate in 100\% of cases.

\section{Results}

Interestingly, 64ms bursts of sound representing bytes turned out to be more
reliable than 128ms bursts, despite 128ms offering more data to verify. Whilst
64ms (at a sample rate of 32kHz and with used frequencies spaced 30Hz apart)
offers 100\% data retrieval, 128ms was only just above 97\%, resulting from half
the tests using 128ms bursts containing an error. This would mean higher level
error control would have to step in.

\section{Future work}

There are a few aspects of Dolphin which could lead to future development. One
would be to investigate the use of \emph{Compressive Sensing} as I outlined in
Section~\ref{sec:compressive} to reduce the number of samples required per tone,
by taking a much smaller random sample instead of a regular interval sample.
This would mean the \emph{Nyquist-Shannon Sampling Theorem} would not apply and
the memory requirement can be lowered. This technique has been shown to be
succsesful in fields such as rapid MRI generation~\cite{CompressiveMRI}, an area
in which accuracy of data is critical, so it could be applied to data transfer
systems.

Another area to improve could be the data transfer rate. Using 32ms bursts the
data transfer rate of Dolphin is currently close to 2kB/min. One reason for this
is the need to only play one tone at once, meaning there can only be one byte
transfered at a time. As I outlined in Section~\ref{sec:compressive}, it is
possible to combine sine waves by adding them together and then the Fourier
Transform would detect two equally strong frequencies which represent the two
bytes sent. This would instantly double the data transfer rate. Determining
in which order the bytes were intended is a matter of encoding. One possible
method would be to encode the first byte as before, and then add the numeric
value of the second to the first and encode that. Therefore, the smaller
frequency would always represent the first byte, and the second can be retrieved
by decoding the frequency and subtracting the value of the first byte.

This method would also make multiplexing transfers possible, sending multiple
files at once by playing them at the same time, which was one of my originally
proposed possibly extensions.

\end{document}